Når vi anvender CLI, bruger vi en shell, der er et program til fortolkning af kommandoer. De to mest almindelige shell-programmer er:
- Bash (Bourne Again Shell): Standard på mange Linux-distributioner og tidligere på macOS.
- Zsh (Z Shell): Standard på macOS fra og med version 10.15 Catalina.
For jer, vil der næppe komme en situation, hvor I vil opleve en forskel på de to. Begge kan tolke alle standard kommandoer. Zsh er dog ofte omtalt som mere brugervenligt og har flere muligheder for personliggørelse, men bash er mere end tilstrækkeligt.
Versionskontrol: Installation af Git i fællesskab
Git og organisering af arbejde
/projektarbejde
└──/backup
├── projekt_281024.docx
├── projekt_311024.docx
├── projekt_041224.docx
├── projekt_final.docx
├── projekt_final2.docx
├── projekt_final3.docx
├── projekt_final_final.docx
└── projekt_FINAL.docx
Versionskontrol
Versionkontrol er et system (software), der holder styr på ændringer af filer over tid, der gør det muligt at genskabe vores tidligere arbejde. Virker for (stort set) alle filer.
På større projekter—hvor flere er involveret—er det vigtigt at have kontrol over, hvem der foretager ændringer, hvilke ændringer der er blevet foretaget, og hvordan man kan rulle tilbage til tidligere versioner, hvis noget går galt.
“[Git] allows you to revert selected files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more.”
![]()
![]()
Versionskontrol
“A local version control system is a local database located on your local computer, in which every file change is stored as a patch. Every patch set contains only the changes made to the file since its last version. In order to see what the file looked like at any given moment, it is necessary to add up all the relevant patches to the file in order until that given moment.
The main problem with this is that everything is stored locally. If anything were to happen to the local database, all the patches would be lost. If anything were to happen to a single version, all the changes made after that version would be lost.
Also, collaborating with other developers or a team is very hard or nearly impossible.”
“A centralized version control system has a single server that contains all the file versions. This enables multiple clients to simultaneously access files on the server, pull them to their local computer or push them onto the server from their local computer. This way, everyone usually knows what everyone else on the project is doing. Administrators have control over who can do what.
This allows for easy collaboration with other developers or a team.
The biggest issue with this structure is that everything is stored on the centralized server. If something were to happen to that server, nobody can save their versioned changes, pull files or collaborate at all. Similar to Local Version Control, if the central database became corrupted, and backups haven’t been kept, you lose the entire history of the project except whatever single snapshots people happen to have on their local machines.”
“With distributed version control systems, clients don’t just check out the latest snapshot of the files from the server, they fully mirror the repository, including its full history. Thus, everyone collaborating on a project owns a local copy of the whole project, i.e. owns their own local database with their own complete history.
With this model, if the server becomes unavailable or dies, any of the client repositories can send a copy of the project’s version to any other client or back onto the server when it becomes available. It is enough that one client contains a correct copy which can then easily be further distributed.”
![]()
Git i praksis
Den “usynlige” .git mappe skaber vi med Git-kommandoen:
Kommandoen skaber en ny undermappe (.git) og er “skelettet” for vores repository. Denne mappe indeholder alle Git’s interne data, der bruges til at spore og administrere versionshistorikken for dit projekt.
I skal være opmærksom på hvilken mappe I befinder jer i, når i kører git init. Fremgangen skal være:
cd <absolut eller relativ stil>
git init
Git i praksis
Versionsstyringsprocessen med afsæt i .git skelletet består af 3 stadier:
- Working Directory: den mappe, hvor vi kørte git init. Alt der ændres her spores af Git, men det gemmes (committes) ikke automatisk
- Staging Area: De ændringer, som du ønsker registreret i næste commit bliver flyttet til et staging area ved git add .. Det er ikke som sådan et “sted”, men et snarer et “tag” til de filer, som Git skal gemme. Ingen ændringer er blevet gemt endnu.
- Repository: Når vi bruger kommandoen git commit -m “besked” gemmes alt staged data i vores Git-repository og alle ændringer siden sidste commit bliver en permanent del af projektets versionshistorik.
